OPC Studio User's Guide and Reference
OPC Wizard Troubleshooting
If you have installed the OPC Studio using the Setup program, and your OPC UA server is running on the default endpoint (opc.tcp://localhost:48040/), you can use an icon in the Launcher application to verify whether the OPC UA server in operational in principle. When you invoke Tools -> OpcCmd - Watch OPC Wizard UA Server, a console window opens with the OpcCmd utility acting as OPC UA client. The client subscribes to a single pre-defined data variable in the server - the one that reports current time as it is known to the server. This test does not give you information about your own functionality that you have added to the server, but verifies whether the server is capable of accepting connections from OPC UA clients, and is responding to OPC UA service requests.
If your endpoint differs from the default, you can invoke the OpcCmd utility yourself, and use a different endpoint address. Simply replace the endpoint URL in the following OpcCmd command by the one that your server uses:
uaClient subscribe opc.tcp://localhost:48040/ --NodeStandardName Server_ServerStatus_CurrentTime
If you want to test your own nodes, you can specify them too. Unless you have changed the namespace URI for the nodes, it will be http://opclabs.com/OpcUA/Custom/Objects. The command to subscribe to a data variable named DataVariable1 directly under the Objects standard folder will then look like this:
uaClient subscribe opc.tcp://localhost:48040/ nsu=http://opclabs.com/OpcUA/Custom/Objects;s=DataVariable1
If you have the Connectivity Explorer application (e.g. if you have installed OPC Wizard using the OPC Studio Setup program, or obtained the Connectivity Explorer separately e.g. through ClickOnce deployment), you can use it for verification of the created OPC UA server as follows:
If the OPC UA client is attempting to connect to the OPC UA server, and the security checks fail, the OPC UA server is required not to disclose the failure reason to the OPC UA client. If you are in a situation in which the secure connections are being rejected by the OPC UA server, and you do not know the reason for it, the information about the rejection reason is to be found only on the OPC UA server side.
On the OPC UA client side, the symptoms of failed security checks can vary. They can be e.g.:
For servers developed with OPC Wizard, you can find more details about why the security checks have failed using the generated log entries, i.e. by adding an event handler for the static LogEntry Event on the EasyUAServer Class. There will be one or more event entries related to the failure. For more information, see Component Event Logging.
Sometimes you may intuitively expect that since you have not established a mutual trust between the OPC UA client and the OPC UA server, the communication attempt will fail. And to your surprise, the OPC UA client can connect to your OPC UA server (on the same computer) just fine, almost as if no security was in place.
What is happening here? If the OPC UA client is developed with QuickOPC and it targets .NET Framework (i.e. not .NET 6+), by default it uses a shared location for its certificate stores, and by the Peer Auto-Trust mechanism (see Providing OPC UA Application Instance Certificate), when it creates its application certificate, it also makes itself trusted to other OPC UA applications on the same computer - provided that they use the same shared certificate stores. Conversely, if the OPC UA server is developed with OPC Wizard and it targets .NET Framework (and not .NET 6+), by default it also uses the shared location for its certificate stores, and through the Peer Auto-Trust mechanism makes itself trusted to other OPC UA applications on the same computer using the same shared certificate stores.
As a result, either the OPC UA server, or the OPC UA client, or neither of them will require you to explicitly establish the trust to its peer application.
If the value of /Objects/Diagnostics/ConversionErrorCount variable (visible to OPC clients) is non-zero, it means that some reads, updates, or writes fail due to conversion errors (see OPC Wizard Error Model).
In some cases, conversion errors cannot be fully prevented, but in most cases their occurrence indicates a programming bug. The easiest way to find which data variables are causing conversion errors is to add an event handler to the ConversionError Event on the EasyUAServer object. The UADataVariableConversionErrorEventArgs object passed to the event handler contains the information related to the error, including the DataVariable that has triggered the error.
The server object keeps has an internal global counter of conversion errors, and increments it automatically whenever a conversion error occurs. This counter (/Objects/Diagnostics/ConversionErrorCount variable) is visible to OPC clients and you can use it to diagnose whether the conversion errors are occurring in your server.
If you add an event handler to some OPC Wizard object, and the event handler throws an exception, the handling of the event will not be properly completed, and the software might be in invalid state, which can manifest itself as mysterious errors. The OPC Wizard catches exceptions thrown from event handlers, and reports them through its event logging mechanism. In order to make sure that such exceptions are not being thrown, inspect the log entries coming through the LogEntry Event on the EasyUAServer object.